Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Part Five
Post-Coding Activities

Many developers think their jobs are finished when they have written enough code. Actually, there are several important tasks that should occur after the code is produced. The developer must test, debug, profile, and optimize the code. An independent tester should also evaluate the code to see if the developer missed anything. As the pieces of the system are finished, they must be assembled and tested. Finally, after the application is certified and packaged for end users, the developers should analyze the project to see if they can learn anything for future projects.

The chapters that follow discuss these post-coding activities in detail. They explain what these tasks are and how you can approach them to create the best applications possible.

CHAPTER 14
Testing

Most programmers know, at least at a theoretical level, that a program must eventually be tested before it is packaged for sale. Unfortunately, most also regard testing as something that occurs quickly at the end of the project. A few fast tests, perhaps a bug fix or two, and the application is off to the end users.

That attitude is guaranteed to cause trouble. At best, the project will be significantly delayed or shipped with unfixed bugs. At worst, last-minute testing will discover design flaws so great that the entire project must be scrapped.

This chapter describes different kinds of testing that you should apply to your development efforts. It covers testing habits that can help you catch bugs as soon as possible, before they can corrupt other parts of the program. Following these techniques will help you reduce the chances of discovering nasty surprises just before the project’s due date.

Use Many Tests

Testing is the process of working with a program to expose bugs. Bugs can be very difficult to find, so no single test is likely to find them all. To catch as many bugs as possible, you need to use a wide variety of tests so each can flush out some fraction of the program’s bugs.

One way to classify tests is by method, scope, and development phase. The method is a specific testing technique. Scope indicates the amount of the system considered by the test. Development phase indicates the time at which the test is performed. These classifications are described in the following sections.

Testing Techniques

There are many different testing techniques, each of which may find some of the bugs in a program. You should use as many techniques as possible so you catch as many bugs as you can. The following list summarizes some of the more important testing methods you can use.

Code walkthrough. Mentally step through the code imagining what it will do at each step.

Code step through. Step through the code in the debugger and watch what it does.

Code review. Explain the code to other developers. This can take the form of a verbal code walkthrough.

Exhaustive input checking. Send every possible input to a routine and verify that it produces correct results.

Black box testing. Send a large number of randomly selected inputs to a routine and verify that it produces correct results.

White box testing. Send a carefully selected set of inputs to a routine and verify that it produces correct results.

Each of these techniques is explained in greater detail later in this chapter.

Test Scope

In addition to using different testing methods, you can test the code at different granularities. You can test individual subroutines and you can test the complete, assembled system. You should test at every level possible to ensure that you catch the greatest number of bugs.

The natural progression for test granularity is: routine, module, subsystem, system. Begin by testing individual routines. When you can find no bugs in the routines, test them together in their modules. For example, suppose you have a .bas module that contains routines for performing matrix multiplication. Study the module and examine the interactions among the routines it contains. Identify the public variables and routines exposed to the outside world and carefully define their characteristics. Write test programs to exercise the features provided by the module.

When you can find no more problems in modules, combine them into subsystems and test them. In Visual Basic, a subsystem might be an ActiveX control, or the client or server in a client/server application.

As you test the subsystems, combine them to form larger subsystems as necessary. Finally, when you have tested all the subsystems, assemble them into the finished application and test them together.

Development Phase

Many programmers think testing is something that occurs only at the end of the project. However, the longer a bug remains undetected, the harder it is to fix. If you defer testing to the end of the project, you are guaranteed to find the bugs as late as possible and many will be difficult to fix. Bugs found at the last minute can have repercussions that may delay the application’s release or result in a buggy product.

Testing must occur throughout the entire development process. You should even test the initial requirements and high-level design. Obviously, you cannot step through the high-level design in the debugger because the design is not program code. You can still apply the other testing techniques, however. You can perform walkthroughs and design reviews to make sure the design makes sense. You can even perform limited forms of black box and white box testing. You and other developers can generate a collection of scenarios and perform walkthroughs to see how the design handles them.

Bugs that enter the project during the design phase can have profound consequences later in the project. They can be so hard to fix later that it is worth almost any amount of effort to fix them immediately.

Step through the Code

Visual Basic is blessed with an extremely powerful debugger. As soon as you finish writing a routine, you should use the debugger to verify that it does what you think it should. Stepping through the code in the debugger gives a very different impression than staring at the code does. Stepping through the routine allows you to find bugs that are easy to miss when you read the source code.

Begin testing by setting a breakpoint on the routine’s first line. Click on the line and press F9 or select the Run menu’s Toggle Breakpoint command. Then start the program. When the program reaches the line you marked, it will stop.

Use Shift-F8, the Run menu’s Step Over command, or the Step Over button to let the program execute the next line of code. To step into subroutines, use F8, the Run menu’s Step Into command, or the Step Into button.

Sometimes it is convenient to skip a series of statements. For example, the routine might contain a For loop that will execute thousands of times. In that case, first step through the loop a few times to make sure it seems to be doing its job properly. Then click on the first line after the loop and place a breakpoint there. Press F5 to make the program run until it reaches the breakpoint.

As you step through the routine, examine the variables. Make sure they contain the values you think they should. If a value seems strange, study the code until you understand how the value was generated. Do not accept the value until you have proven to yourself that it is correct.

Continue stepping through the code until you reach the end of the routine. Then start over again and follow a different path through the code. If an If statement’s condition was True the first time you walked through the routine, make it False this time. Repeat the entire process, examining variables to make sure they have the correct values, until you reach the end of the routine.

Then do it again, and again, and again until you have executed every line of code in the routine. Do not skip any code assuming it is too simple to be wrong. Assume every line could be wrong. Be patient. Thoroughly walking through a subroutine can take quite a while. The time you spend now, however, will be more than repaid in reduced debugging time later.